An entity who has subscribed for the provision of services to a mobile device such as a mobile telephone is required to have an associated Subscriber Identity Module (SIM), which identifies the subscriber and the services to which the subscriber is entitled. The type of SIM required depends on the particular mobile device and the network over which it is to be used, for example a mobile device operating over the IP Multimedia Subsystem (IMS) requires an IP Multimedia Services Identity Module (ISIM), whereas a mobile device operating over the Universal Mobile Telecommunications System (UMTS) requires a Universal Subscriber Identity Module (USIM)
When a mobile device is purchased it is necessary to provide the device with a SIM before the device can be used. The process is referred to a “provisioning” the device. Currently, the provisioning process is normally carried out manually, for example by sales personnel when the mobile device is purchased, or with a partial degree of automation, eg via a Point of Sale (PoS). However, the large number of mobile devices that are sold make manual or part-manual provisioning processes undesirable. SIP-based M2M (machine to machine) and CCE (connected consumer electronics) devices—including gateways, proxies and Back-2-Back User Agents (B2BUA)—are likely to face a similar problem when handling subscription credentials. In a world of billions of devices, the currently established manual or semi-automated procedures for handling IMS credentials in Universal Integrated Circuit Cards (UICC) are non-efficient, non-scalable and non-user friendly, preventing a wider acceptance and penetration of the IMS services and applications.
For example, a person may purchase one or more IMS devices abroad, or take out a subscription to one or more IMS services while abroad, and would like to enjoy the IMS applications as soon as possible without waiting to come home and going to a retailer to obtain an ISIM. A subscriber may also add new IMS devices or services to his/her subscription or even change IMS operator after some years due to moving.
There is a need for a solution that allows remote management of IMS credentials for various M2M and CCE business models where minimal or no human intervention is needed for scenarios where the user is actively involved in the management process.
WO 2009/098130 and WO 2008/128873 propose a downloadable USIM (DLUSIM), alternatively referred to as Machine Communication Identity Module (MCIM). We will use the terms MCIM and DLUSIM interchangeably in the rest of this document.
There are two aspects considered in the MCIM/DLUSIM architecture: terminal and network aspects. On the terminal side, the traditional UICC is replaced with the more generic Trusted (Execution) Environment. On the network side, two new network nodes/technical functions are introduced: the Discovery Function and the Provisioning Function. The former allows the M2M equipment to discover the selected home operator and latter enables the download of the subscription credentials.
MCIM/DLUSIM can be seen as a high-level framework, and as such it can be used for remote provisioning of ISIM applications as well.
The TRusted Environment (TRE) in the device provides some hardware and software protection for the provisioning, storage, execution and management of applications such as USIM or ISIM. The TRE might be a completely separate module (e.g. UICC or TPM) or it might share memory and CPU etc. with the device (e.g. ARM's TrustZone).
Since it might be possible to move the TRE between devices (as in the UICC case) a subscription is bound to the TRE identity rather than the device identity. Furthermore, since the device is not fully trusted, decryption of the IMS credentials must be performed inside the TRE, and not in the hosting device. As the TRE becomes an integral part of the device, in the rest of this document we will assume that the device is TRE-equipped. Hence, when referring to ISIM requests and ISIM data sent from/to the device, is meant that request or data are sent from/to the TRE of the device. Where necessary for clarity of explanation, the difference between the TRE and the hosting device will be mentioned.